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Dear Sir: 

In response to the Notices of Non-Compliant Appeal Brief, mailed 9 November 2010, 
Appellant respectfully submits this supplemental Appeal Brief to correct deficiencies in the 
Appeal Brief filed on 24 May 2010. This Supplemental Appeal Brief is herein reformatted to 
comply with the presently accepted Appeal Brief format in compliance with 37 C.F.R. § 
41.37(a). 

In accordance with 37 C.F.R. § 41.37(a), Appellant respectfully submits this 
Supplemental Appeal Brief in furtherance of the Notice of Appeal filed in the above-identified 
application on 6 April 2010, which appeals the Final Office Action dated 1 March 2010. In 
compliance with 37 C.F.R. § 41.37(a)(1), Appellant submits one (1) copy of this Appeal Brief. 
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I. REAL PARTY IN INTEREST 

Symantec Corporation is the real party in interest in the present application. An 
assignment of all rights in the present application to Symantec Corporation was recorded by the 
U.S. Patent and Trademark Office on 6 September 2007 at Reel 019781, Frame 0651. 

II. RELATED APPEALS AND INTERFERENCES 

A notice of Appeal and a request for Pre-Appeal Conference were previously filed in this 
case on 12 March 2008. A Notice of Panel Decision from Pre-Appeal Brief review was mailed 
on 24 April 2008, a copy of which is included in the Related Proceedings Appendix. The Panel 
reopened prosecution. 

Appellant is not aware of any other appeals, interferences, or judicial proceedings that 
will directly affect, be directly affected by, or have a bearing on the Board's decision in this 
appeal. 

III. STATUS OF CLAIMS 

The Status of the Claims is as follows: 

Claims 1-8 (Rejected) 

Claim 9 (Canceled) 

Claims 10-18 (Rejected) 

Claim 19 (Canceled) 

Claims 20-28 (Rejected) 

Claim 29 (Canceled) 

Claims 30-38 (Rejected) 

Claim 39 (Canceled) 
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Claims 40-43 (Rejected) 

Appellant hereby appeals the rejections of claims 1-8, 10-18, 20-28, 30-38, and 40-43 
which are presented in the Claims Appendix. 

IV. STATUS OF AMENDMENTS 

No amendments to the claims have been made subsequent to the Final Office Action 
dated 1 March 2010, which Action is the subject of this Appeal. A copy of the pending claims is 
attached to this Brief in the Appendix. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 

The following description is provided for illustrative purposes and is not intended to limit 
the scope of the invention. 

The present invention relates to methods, apparatus, and computer-readable storage 
media for backing up file systems in partitions of local storage devices, such as, for example, 
partitions on a personal computer hard drive. 

Claims 1-8 and 10 

Described is a method for backing up a file system in a partition comprising a plurality of 
allocation units, the method comprising: 

creating a locally- stored image file by copying each allocation unit occupied by a 
plurality of files of the file system to the locally-stored image file {page 5, paragraph 17; page 
6, paragraph 18; page 11, paragraph 42; page 12, paragraphs 46 and 49; page 20, paragraph 
77; Fig. 3, 204, 302, 306; Fig. 9, 902}, wherein the locally-stored image file is located within the 
same partition as the file system being backed up {page 5, paragraph 17; page 11, paragraphs 
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42, 44, and 45; page 12, paragraph 49; page 20, paragraph 77; Fig. 2, 102, 104, 204; Fig. 9, 
902}; 

adding a directory map to the locally-stored image file that associates copied allocation 
units in the locally-stored image file with names of corresponding files from the file system 
{page 5, paragraph 17; page 14, paragraph 54; page 18, paragraph 70; page 19, paragraph 78; 
page 21, paragraph 83; Fig. 3, 312; Fig. 9, 904}; and 

subsequent to creating the locally-stored image file, protecting the locally- stored image 
file from accidental user deletion or modification by initiating a process at system startup that 
opens the locally- stored image file to block subsequent processes from accessing the locally- 
stored image file {page 6, paragraphs 18 and 22; page 11, paragraph 45; page 15, paragraph 
60; page 16, paragraph 62; page 20, paragraph 79; page 21, paragraph 83; Fig. 9, 906}. 

Claims 11-18 and 20 

Described is a method for restoring a file system to a partition comprising a plurality of 
allocation units, the method comprising: 

accessing a locally-stored image file located within the partition to which the file system 
is to be restored {page 6, paragraph 20; page 17, paragraph 66; page 21, paragraph 81; Fig. 9, 
908}, the locally- stored image file comprising a directory map and file data for a plurality of files 
{page 5, paragraph 17; page 14, paragraph 54; page 18, paragraph 70; page 19, paragraph 78; 
page 21, paragraph 83; Fig. 3, 312; Fig. 9, 904}; 

initializing at least a subset of the allocation units of the partition not occupied by the 
locally- stored image file including one or more allocation units used for a directory area of the 
partition {page 6, paragraph 21; page 17, paragraph 68; Fig. 9, 910}; 
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extracting the file data from the locally-stored image file into the initialized allocation 
units without disturbing the locally-stored image file {page 6, paragraph 21; page 18, 
paragraph 69; page 19, paragraph 75; page 20, paragraph 76; page 21, paragraph 82; Fig. 9, 
910}; 

creating a new directory area for the partition using the directory map {page 16, 
paragraph 64; page 18, paragraphs 70-72; page 20, paragraph 76; page 21, paragraph 83; Fig. 
7, 70S}; and 

protecting the locally-stored image file from accidental user deletion or modification 
subsequent to creation of the locally-stored image file by initiating a process at system startup 
that opens the locally-stored image file to block subsequent processes from accessing the locally- 
stored image file {page 6, paragraphs 18 and 22; page 11, paragraph 45; page 15, paragraph 
60; page 16, paragraph 62; page 20, paragraph 79; page 21, paragraph 83; Fig. 9, 906}. 

Claims 21-28 and 30 

Described is an apparatus for backing up a file system in a partition comprising a 
plurality of allocation units, the apparatus comprising: 

a processor {page 6, paragraph 18; page 9, paragraphs 34-36; page 12, paragraph 46; 
page 15, paragraph 60; page 16, paragraph 62; page 17, paragraph 68; Fig. 5, 504; Fig. 6, 
602, 604}; 

a local imager {page 5, paragraph 17; page 11, paragraphs 42-45; page 12, paragraph 
49; page 13, paragraphs 50-52; page 14, paragraphs 54-56; page 15, paragraphs 57-59; page 
16, paragraph 64; page 20, paragraphs 77-78; Fig. 2, 202; Fig. 3, 202; Fig. 4, 202; Fig. 8, 202} 
programmed to create a locally- stored image file by copying each allocation unit occupied by a 
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plurality of files of the file system to the locally-stored image file {page 5, paragraph 1 7; page 
6, paragraph 18; page 11, paragraph 42; page 12, paragraphs 46 and 49; page 20, paragraph 
77; Fig. 3, 204, 302, 306; Fig. 9, 902}, wherein the locally-stored image file is located within the 
same partition as the file system being backed up {page 5, paragraph 17; page 11, paragraphs 
42, 44, and 45; page 12, paragraph 49; page 20, paragraph 77; Fig. 2, 102, 104, 204; Fig. 9, 
902}, and wherein the local imager is configured to add a directory map to the locally- stored 
image file that associates copied allocation units in the locally- stored image file with names of 
corresponding files from the file system {page 5, paragraph 17; page 14, paragraph 54; page 
18, paragraph 70; page 19, paragraph 78; page 21, paragraph 83; Fig. 3, 312; Fig. 9, 904}; 
and 

a protection component {page 6, paragraph 18; page 20, paragraph 79; page 21, 
paragraph 83} programmed to protect the locally-stored image file from accidental user deletion 
or modification subsequent to creation of the locally-stored image file by initiating a process at 
system startup that opens the locally-stored image file to block subsequent processes from 
accessing the locally- stored image file {page 6, paragraphs 18 and 22; page 11, paragraph 45; 
page 15, paragraph 60; page 16, paragraph 62; page 20, paragraph 79; page 21, paragraph 83; 
Fig. 9, 906}. 

Claims 31-38 and 40 

Described is an apparatus for restoring a file system to a partition comprising a plurality 
of allocation units, the apparatus comprising: 
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a processor {page 6, paragraph 18; page 9, paragraphs 34-36; page 12, paragraph 46; 
page 15, paragraph 60; page 16, paragraph 62; page 17, paragraph 68; Fig. 5, 504; Fig. 6, 
602, 604}; 

an image locater {page 6, paragraph 20; page 16, paragraph 64; page 1 7, paragraphs 
65-67; page 21, paragraph 81; Fig. 7, 702} to find a locally- stored image file located within the 
partition to which the file system is to be restored {page 6, paragraph 20; page 17, paragraph 
66; page 21, paragraph 81; Fig. 9, 908}, the locally- stored image file comprising a directory 
map and file data for a plurality of files {page 5, paragraph 17; page 14, paragraph 54; page 
18, paragraph 70; page 19, paragraph 78; page 21, paragraph 83; Fig. 3, 312; Fig. 9, 904}; 

a media formatter {page 6, paragraph 21; page 16, paragraph 64; page 17, paragraph 
68; page 21, paragraph 82; Fig. 7, 704} to initialize at least a subset of the allocation units of 
the partition not occupied by the locally-stored image file including one or more allocation units 
used for a directory area of the partition {page 6, paragraph 21; page 17, paragraph 68; Fig. 9, 
910}; 

a data extractor {page 6, paragraph 21; page 16, paragraph 64; page 18, paragraph 69- 
70; page 21, paragraph 82; Fig. 7, 706} to extract the file data from the locally- stored image file 
into the initialized allocation units without disturbing the locally- stored image file {page 6, 
paragraph 21; page 18, paragraph 69; page 19, paragraph 75; page 20, paragraph 76; page 21, 
paragraph 82; Fig. 9, 910}; 

a directory area builder {page 6, paragraph 22; page 16, paragraph 64; page 18, 

paragraph 70-72; page 21, paragraph 83; Fig. 7, 708} to build a new directory area for the 

partition using the directory map {page 16, paragraph 64; page 18, paragraphs 70-72; page 20, 

paragraph 76; page 21, paragraph 83; Fig. 7, 708}; and 
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a protection component {page 6, paragraph 18; page 20, paragraph 79; page 21, 
paragraph 83} programmed to protect the locally-stored image file from accidental user deletion 
or modification subsequent to creation of the locally-stored image file by initiating a process at 
system startup that opens the locally- stored image file to block subsequent processes from 
accessing the locally- stored image file {page 6, paragraphs 18 and 22; page 11, paragraph 45; 
page 15, paragraph 60; page 16, paragraph 62; page 20, paragraph 79; page 21, paragraph 83; 
Fig. 9, 906}. 

Claim 41 

Described is a method for localized backup and restoration of a file system in a partition 
comprising a plurality of allocation units, the method comprising: 

creating a locally-stored image file by copying each allocation unit occupied by a 
plurality of files of the file system to the locally-stored image file {page 5, paragraph 17; page 
6, paragraph 18; page 11, paragraph 42; page 12, paragraphs 46 and 49; page 20, paragraph 
77; Fig. 3, 204, 302, 306; Fig. 9, 902}, wherein the locally-stored image file is located within the 
same partition as the file system being backed up {page 5, paragraph 17; page 11, paragraphs 
42, 44, and 45; page 12, paragraph 49; page 20, paragraph 77; Fig. 2, 102, 104, 204; Fig. 9, 
902}; 

adding a directory map to the locally-stored image file that associates copied allocation 
units in the locally-stored image file with names of corresponding files from the file system 
{page 5, paragraph 17; page 14, paragraph 54; page 18, paragraph 70; page 19, paragraph 78; 
page 21, paragraph 83; Fig. 3, 312; Fig. 9, 904}; 
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locating the locally- stored image file within the partition {page 11, paragraph 45; page 
14, paragraph 56; Fig. 9, 908}; 

initializing at least a subset of the allocation units of the partition not occupied by the 
locally- stored image file including one or more allocation units used for a directory area of the 
partition {page 6, paragraph 21; page 17, paragraph 68; Fig. 9, 910}; 

extracting file data from the locally- stored image file into the initialized allocation units 
without disturbing the locally- stored image file {page 6, paragraph 21; page 18, paragraph 69; 
page 19, paragraph 75; page 20, paragraph 76; page 21, paragraph 82; Fig. 9, 910}; 

creating a new directory area for the partition using the directory map {page 16, 
paragraph 64; page 18, paragraphs 70-72; page 20, paragraph 76; page 21, paragraph 83; Fig. 
7, 708}; and 

subsequent to creating the locally-stored image file, protecting the locally- stored image 
file from accidental user deletion or modification by initiating a process at system startup that 
opens the locally- stored image file to block subsequent processes from accessing the locally- 
stored image file {page 6, paragraphs 18 and 22; page 11, paragraph 45; page 15, paragraph 
60; page 16, paragraph 62; page 20, paragraph 79; page 21, paragraph 83; Fig. 9, 906}. 

Claim 42 

Described is a computer-readable storage medium comprising program code for backing 
up a file system in a partition comprising a plurality of allocation units, the computer-readable 
storage medium comprising: 

program code for creating a locally- stored image file by copying each allocation unit 
occupied by a plurality of files of the file system to a locally- stored image file {page 5, 
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paragraph 17; page 6, paragraph 18; page 11, paragraph 42; page 12, paragraphs 46 and 49; 
page 20, paragraph 77; Fig. 3, 204, 302, 306; Fig. 9, 902}, wherein the locally- stored image file 
is located within the same partition as the file system being backed up {page 5, paragraph 17; 
page 11, paragraphs 42, 44, and 45; page 12, paragraph 49; page 20, paragraph 77; Fig. 2, 
102, 104, 204; Fig. 9, 902}; 

program code for adding a directory map to the locally- stored image file that associates 
copied allocation units in the locally- stored image file with names of corresponding files from 
the file system {page 5, paragraph 17; page 14, paragraph 54; page 18, paragraph 70; page 19, 
paragraph 78; page 21, paragraph 83; Fig. 3, 312; Fig. 9, 904}; and 

program code for protecting the locally-stored image file from accidental user deletion or 
modification subsequent to creation of the locally-stored image file by initiating a process at 
system startup that opens the locally- stored image file to block subsequent processes from 
accessing the locally- stored image file {page 6, paragraphs 18 and 22; page 11, paragraph 45; 
page 15, paragraph 60; page 16, paragraph 62; page 20, paragraph 79; page 21, paragraph 83; 
Fig. 9, 906}. 

Claim 43 

Described is a computer-readable storage medium comprising program code for restoring 
a file system to a partition comprising a plurality of allocation units, the computer-readable 
storage medium comprising: 

program code to access a locally- stored image file located within the partition to which 
the file system is to be restored {page 6, paragraph 20; page 17, paragraph 66; page 21, 
paragraph 81; Fig. 9, 908}, the locally-stored image file comprising a directory map and file 
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data for a plurality of files {page 5, paragraph 17; page 14, paragraph 54; page 18, paragraph 
70; page 19, paragraph 78; page 21, paragraph 83; Fig. 3, 312; Fig. 9, 904}; 

program code to initialize at least a subset of the allocation units of the partition not 
occupied by the locally-stored image file including one or more allocation units used for a 
directory area of the partition {page 6, paragraph 21; page 17, paragraph 68; Fig. 9, 910}; 

program code to extract the file data from the locally-stored image file into the initialized 
allocation units without disturbing the locally- stored image file {page 6, paragraph 21; page 18, 
paragraph 69; page 19, paragraph 75; page 20, paragraph 76; page 21, paragraph 82; Fig. 9, 
910}; 

program code to create a new directory area for the partition using the directory map 
{page 16, paragraph 64; page 18, paragraphs 70-72; page 20, paragraph 76; page 21, 
paragraph 83; Fig. 7, 708}; and 

program code to protect the locally-stored image file from accidental user deletion or 
modification subsequent to creation of the locally-stored image file by initiating a process at 
system startup that opens the locally- stored image file to block subsequent processes from 
accessing the locally- stored image file {page 6, paragraphs 18 and 22; page 11, paragraph 45; 
page 15, paragraph 60; page 16, paragraph 62; page 20, paragraph 79; page 21, paragraph 83; 
Fig. 9, 906}. 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Claims 1-8, 10-18, 20-28, 30-38, and 40-43 stand rejected under 35 U.S.C. § 103(a) as 
being unpatentable over U.S. Patent No. 6,615,365 to Jenevein et al. ("Jenevein") in view of U.S. 
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Patent No. 6,026,016 to Gafken ("Gafken"). Appellant respectfully requests that these grounds 
of rejection be reviewed in the instant Appeal. 

VII. ARGUMENT 

In the Final Office Action of 1 March 2010, the Examiner erred in rejecting claims 1-8, 
10-18, 20-28, 30-38, and 40-43 under 35 U.S.C. § 103(a) as being unpatentable over U.S. Patent 
No. 6,615,365 to Jenevein et al. ("Jenevein") in view of U.S. Patent No. 6,026,016 to Gafken 
("Gafken"). 

35 U.S.C. § 103(a) recites, in part: 

A patent may not be obtained though the invention is not identically disclosed or 
described as set forth in section 102 of this title, if the differences between the 
subject matter sought to be patented and the prior art are such that the subject 
matter as a whole would have been obvious at the time the invention was made to 
a person having ordinary skill in the art to which said subject matter pertains. 

To establish prima facie obviousness of a claimed invention, "[a]ll words in a claim must be 

considered in judging the patentability of that claim against the prior art." In re Wilson, 424 F.2d 

1382, 1385, 165 USPQ 494, 496 (CCPA 1970). 

Appellant respectfully submits that the cited references, even if combined, do not 

establish a prima facie case of obviousness because they do not show, teach, or suggest all 

claimed features. 

A. Statement of Facts 

In the rejections of independent claims 1, 11, 21, 31, 41, 42, and 43, the Examiner 
recognizes that "Jenevein does not appear to teach protection by initiating a process at system 
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startup that opens the locally-stored image file to block subsequent processes from accessing the 
locally- stored image file." Final Office Action dated March 1, 2010, page 3. 

In an attempt to remedy the conceded deficiencies of Jenevein, the Examiner asserts that 
Gafken "teaches initiating a process at system startup (col. 3 lines 24-31 and col. 12 lines 8-11) 
that opens (fig. 5, e.g. numeral 525) the locally-stored image file to block subsequent processes 
from accessing the locally- stored image file (col. 3, lines 29-31, col. 12 lines 8-11) for proving 
[sic] a locking mechanism that operates during start-up to protect critical information stored in 
blocks from undesired alterations (Gafken, col. 10, lines 30-33)." Final Office Action dated 
March 1,2010, page 3. 

Gafken is directed to a "hardware block locking" system that uses a block-locking circuit 
140 to prevent "viruses and other destructive sources of memory corruption" from altering data 
(such as a system's BIOS) stored in specific blocks of memory within a memory array 130. Col. 
14, lines 27-39; col. 4, lines 27-34; Fig. 1. According to Gafken, block locking circuit 140 
includes a lock bit array 315 that contains a plurality of sets of protection bits "arranged in 
segments 0-N to correspond respectively to blocks 0-N of the memory array 130." Col. 6, lines 
4-59. Gafken also explains that each set of protection bits within lock bit array 315 "stores a 
value indicating the protection status ["locked, unlocked, or locked-down"] of the corresponding 
block of the memory array [that is to be protected]." Id. Thus, by changing a protection bit set's 
value to "locked" or "locked-down," the system in Gafken may prevent a corresponding block of 
memory within memory array 130 (which, according to Gafken, is often "used to store the start- 
up and/or basic input/output system (BIOS) routines that are executed when a computer system 
is reset or turned on") "from being accessed for program or erase operations." Id.; col. 1, lines 
19-22. 
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B. The Cited References Fail to Disclose, Teach, or Suggest the Protection Feature of 
Claims 1-8, 10-18, 20-28, 30-38, and 40-43 

As will be explained in greater detail below, the cited references fail to teach the 
protection feature of claims 1-8, 10-18, 20-28, 30-38, and 40-43. In the Final Office Action, the 
Examiner acknowledges that Jenevein does not teach of "protecting [a] locally- stored image file 
from accidental user deletion of modification by initiating a process at system startup that opens 
the locally- stored image file to block subsequent processes from accessing the locally-stored 
image file," as recited in independent claims 1, 11, 12, 31, 41, 42, and 43. Final Office Action, 
mailed March 1, 2010, page 3. However, in an attempt to remedy these conceded deficiencies, 
the Examiner alleges that: 

"Gafken ... teaches initiating a process at system startup (col. 3 lines 24-31 and 
col. 12 lines 8-11) that opens (fig. 5, e.g. numeral 525) the locally-stored image 
file to block subsequent processes from accessing the locally- stored image file 
(col. 3, lines 29-31, col. 12 lines 8-11) for proving [sic] a locking mechanism that 
operates during start-up to protect critical information stored in blocks from 
undesired alterations (Gafken, col. 10, lines 30-33)." 

Id. 

Gafken does not, however, teach of protecting a locally-stored image file by initiating a 
process at system startup that opens the locally- stored image file to block subsequent processes 
from accessing the locally- stored image file. Instead, and as will be described in greater detail 
below, Gafken merely describes using a hardware circuit to regulate access to specific memory 
blocks within a nonvolatile memory that contains a system's basic input/output system (BIOS). 
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Gafken describes a "hardware block locking" system that uses a block-locking circuit 140 
to prevent "viruses and other destructive sources of memory corruption" from altering data (such 
as a system's BIOS) stored in specific blocks of memory within a memory array 130. Col. 14, 
lines 27-39; col. 4, lines 27-34; Fig. 1. According to Gafken, block locking circuit 140 includes 
a lock bit array 315 that contains a plurality of sets of protection bits "arranged in segments 0-N 
to correspond respectively to blocks 0-N of the memory array 130." Col. 6, lines 4-59. Gafken 
also explains that each set of protection bits within lock bit array 315 "stores a value indicating 
the protection status ["locked, unlocked, or locked-down"] of the corresponding block of the 
memory array [that is to be protected]." Id. Thus, by changing a protection bit set's value to 
"locked" or "locked-down," the system in Gafken may prevent a corresponding block of memory 
within memory array 130 (which, according to Gafken, is often "used to store the start-up and/or 
basic input/output system (BIOS) routines that are executed when a computer system is reset or 
turned on") "from being accessed for program or erase operations." Id.; col. 1, lines 19-22. 

In summary, in order to securely update a system's BIOS stored within memory array 

130, the system disclosed in Gafken must: 1) unlock access to the blocks of memory within 

memory array 130 that contain the system's BIOS by changing the value of corresponding 

protection bits within lock bit array 315 from "locked" or "locked down" to "unlocked," 2) 

update/flash the system's BIOS by copying a new BIOS image ("obtained from a mass storage 

device ... or over a network or from the World Wide Web") to the blocks of memory within 

memory array 130 that contain the system's BIOS, and then 3) re-lock the blocks of memory 

within memory array 130 that contain the updated BIOS by changing the value of the 

corresponding protection bits within lock bit array 315 from "unlocked" to "locked down" or 

"locked." See, e.g., col. 12, lines 38-48 and col. 13, line 26 to col. 14, line 10. 
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As is clear from the above summary, Gafken clearly fails to teach of protecting memory 
blocks within a memory array 130 that contain a system's current BIOS by opening these blocks 
during system startup, let alone protecting a locally stored image file by initiating a process at 
system startup that opens the locally stored image file, as recited in the independent claims of the 
instant application. While col. 12, lines 8-11 of Gafken teaches that, during a BIOS update 
process, boot code may maintain exclusive control of system 100 in order to ensure that "viruses, 
system software and/or other processor commands cannot alter the information stored in the 
memory array 130 unless the boot code 330 specifically provides for the changes," Gafken fails 
to teach or suggest that this boot code protects the memory blocks within memory array 130 that 
contain the system's BIOS by opening these memory blocks. Instead, Gafken merely teaches of 
using a hardware circuit (block locking circuit 140) to protect access to these memory blocks, as 
detailed above. 

In the most-recent Final Office Action, the Examiner appears to argue that Gafken 

protects blocks of memory within memory array 130 that contain a system's BIOS by initiating a 

process at system startup that opens a separate "code image" that is "to be used to update code 

[such as a system's BIOS] previously stored in the memory array 130." Final Office Action, 

mailed March 1, 2010, page 3. The Examiner's argument fails for at least the following reasons: 

1) Gafken teaches that the blocks of memory within memory array 130 that contain the system's 

BIOS are protected by activating specific protection bits within lock bit array 315 of block 

locking circuit 140, not by opening a "code image" that contains an updated BIOS image and 2) 

even if (for the sake of argument) Gafken taught of initiating a process during system startup that 

opens an image file (such as the "code image" disclosed in Gafken), the independent claims of 

the instant application recite "protecting [a] locally-stored image file ... by initiating a process at 
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system startup that opens the locally stored image file," not protecting blocks of memory in a 
nonvolatile memory array by opening a separate image file. The Examiner appears to be using 
the claims of the instant application as a blueprint for attempting to read features into Gafken that 
are not taught or suggested anywhere in Gafken. 

Moreover, the "code image" disclosed in Gafken and cited by the Examiner is clearly not 
analogous to the locally stored image file (which, according to the claims of the instant 
application, contains a backup of a file system) recited in the claims of the instant application. 
For example, Gafken clearly states that this code image is "used to update code [such as a 
system's BIOS] previously stored in the memory array 130." Col. 12, line 38-44 and Fig. 1. In 
other words, the code image described by Gafken merely contains code (such as a new BIOS 
image) to be used to update the blocks of memory within memory array 130. This is clearly 
different from a "locally- stored image file" that contains "a plurality of files of [a] file system" 
(i.e., a backup of a file system) and is "located within the same partition as the file system being 
backed up," as recited in the claims of the instant application. 

For at least the above reasons, Gafken fails to teach or suggest "protecting the locally- 
stored image file from accidental user deletion or modification by initiating a process at system 
startup that opens the locally-stored image file to block subsequent processes from accessing the 
locally- stored image file," as recited in claims 1, 11, 21, 31, 41, 42, and 43. Accordingly, 
Appellant submits that claims 1, 11, 21, 31, 41, 42, and 43 distinguish over the proposed 
combination of Jenevein and Gafken and are in condition for allowance. 

Claims 2-8, 10, 12-18, 20, 22-28, 30, 32-38, and 40 depend from claim 1, 11, 21, or 31. 
By virtue of this dependency, Appellant submits that claims 2-8, 10, 12-18, 20, 22-28, 30, 32-38, 
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and 40 distinguish over the proposed combination of Jenevein and Gafken for at least the same 
reasons given above with respect to claims 1, 11, 21, and 31. 
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CONCLUSION 

For at least the foregoing reasons, Appellant believes that each of the finally rejected 
claims in this application is in immediate condition for allowance. Accordingly, Appellant 
respectfully requests the reversal of the rejections of these claims and allowance of the same. 

Respectfully submitted, 



Date: 



8 December 2010 




Jonathan R. Lee 
Registration No. 56,561 
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VIII. CLAIMS APPENDIX 

The following listing of claims is a clean copy of all claims pending in the application. 

1. (Rejected) A method for backing up a file system in a partition comprising a plurality 
of allocation units, the method comprising: 

creating a locally- stored image file by copying each allocation unit occupied by a 
plurality of files of the file system to the locally- stored image file, wherein the locally- stored 
image file is located within the same partition as the file system being backed up; 

adding a directory map to the locally-stored image file that associates copied allocation 
units in the locally- stored image file with names of corresponding files from the file system; and 

subsequent to creating the locally-stored image file, protecting the locally- stored image 
file from accidental user deletion or modification by initiating a process at system startup that 
opens the locally-stored image file to block subsequent processes from accessing the locally- 
stored image file. 

2. (Rejected) The method of claim 1, wherein copying comprises compressing at least a 
subset of the allocation units. 

3. (Rejected) The method of claim 1, wherein copying comprises: 
maintaining a record of a pre-imaging state of the file system; and 

copying only allocation units occupied by files included within the pre-imaging state of 
the file system. 
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4. (Rejected) The method of claim 1, wherein adding comprises grouping within the 
locally- stored image file the copied allocation units for individual files of the file system. 

5. (Rejected) The method of claim 1, wherein copying comprises storing within the 
locally- stored image file one or more attributes related to each file, wherein the attributes 
comprise at least one of ownership attributes, access-control attributes, timestamp attributes, 
archival attributes, indexing attributes, encryption attributes, and compression attributes. 

6. (Rejected) The method of claim 1 , further comprising marking a beginning point of the 
locally- stored image file to assist in locating the locally-stored image file in the event of 
directory area corruption. 

7. (Rejected) The method of claim 6, wherein marking comprises storing a unique 
beginning-of-image marker at an initial allocation unit occupied by the locally-stored image file. 

8. (Rejected) The method of claim 6, wherein marking comprises storing, at a 
predetermined area of the partition, a location of an initial allocation unit occupied by the 
locally- stored image file. 



9. (Canceled) 
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10. (Rejected) The method of claim 1, wherein protecting the locally- stored image file 
further comprises providing a filter driver that intercepts and denies requests to access the 
locally- stored image file. 

11. (Rejected) A method for restoring a file system to a partition comprising a plurality of 
allocation units, the method comprising: 

accessing a locally-stored image file located within the partition to which the file system 
is to be restored, the locally- stored image file comprising a directory map and file data for a 
plurality of files; 

initializing at least a subset of the allocation units of the partition not occupied by the 
locally- stored image file including one or more allocation units used for a directory area of the 
partition; 

extracting the file data from the locally- stored image file into the initialized allocation 
units without disturbing the locally- stored image file; 

creating a new directory area for the partition using the directory map; and 
protecting the locally-stored image file from accidental user deletion or modification 
subsequent to creation of the locally- stored image file by initiating a process at system startup 
that opens the locally-stored image file to block subsequent processes from accessing the locally- 
stored image file. 
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12. (Rejected) The method of claim 11, wherein the directory map associates names for 
the plurality of files with corresponding portions of the file data, and wherein creating comprises 
generating a new directory area for the partition that associates the file names with the extracted 
file data. 

13. (Rejected) The method of claim 11, wherein creating comprises adding an indication 
of the locally- stored image file to the new directory area. 

14. (Rejected) The method of claim 11, wherein extracting comprises decompressing at 
least a subset of the file data. 

15. (Rejected) The method of claim 11, wherein the directory map indicates at least one 
attribute for a file, and wherein creating comprises setting the at least one attribute for the file in 
the directory area, wherein the at least one attribute comprises at least one of an ownership 
attribute, an access control attribute, a timestamp attribute, an archival attribute, an indexing 
attribute, an encryption attribute, and a compression attribute. 

16. (Rejected) The method of claim 11, wherein accessing comprises searching for an 
allocation unit containing a unique beginning-of-image marker for the locally- stored image file. 

17. (Rejected) The method of claim 11, wherein accessing comprises reading from a 
predetermined area of the partition a location of an initial allocation unit of the locally- stored 
image file. 
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18. (Rejected) The method of claim 11, further comprising defragmenting the locally- 
stored image file within the partition prior to extracting the file data. 

19. (Canceled) 

20. (Rejected) The method of claim 11, wherein protecting the locally-stored image file 
further comprises providing a filter driver that intercepts and denies requests to access the 
locally- stored image file. 

21. (Rejected) An apparatus for backing up a file system in a partition comprising a 
plurality of allocation units, the apparatus comprising: 

a processor; 

a local imager programmed to create a locally-stored image file by copying each 
allocation unit occupied by a plurality of files of the file system to the locally- stored image file, 
wherein the locally- stored image file is located within the same partition as the file system being 
backed up, and wherein the local imager is configured to add a directory map to the locally- 
stored image file that associates copied allocation units in the locally-stored image file with 
names of corresponding files from the file system; and 

a protection component programmed to protect the locally- stored image file from 
accidental user deletion or modification subsequent to creation of the locally- stored image file by 
initiating a process at system startup that opens the locally-stored image file to block subsequent 
processes from accessing the locally- stored image file. 
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22. (Rejected) The apparatus of claim 21, wherein the local imager is configured to 
compress at least a subset of the allocation units copied to the locally- stored image file. 

23. (Rejected) The apparatus of claim 21, wherein the local imager is configured to 
maintain a record of a pre-imaging state of the file system and to copy only allocation units 
occupied by files included within the pre-imaging state of the file system. 

24. (Rejected) The apparatus of claim 21. wherein the local imager is configured to group 
within the locally- stored image file the copied allocation units for individual files of the file 
system. 

25. (Rejected) The apparatus of claim 21, wherein the local imager is configured to store 
within the locally-stored image file one or more attributes relating to at least one file of the file 
system, wherein the file attributes comprise at least one of ownership attributes, access-control 
attributes, timestamp attributes, archival attributes, indexing attributes, encryption attributes, and 
compression attributes. 

26. (Rejected) The apparatus of claim 21, wherein the local imager is configured to mark 
a beginning point of the locally-stored image file to assist in locating the locally-stored image 
file in the event of directory area corruption. 
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27. (Rejected) The apparatus of claim 26, wherein the local imager is configured to mark 
the beginning point by storing a unique beginning-of-image marker at an initial allocation unit 
occupied by the locally-stored image file. 

28. (Rejected) The apparatus of claim 26, wherein the local imager is configured to mark 
the beginning point by storing, at a predetermined area of the partition, a location of an initial 
allocation unit occupied by the locally- stored image file. 

29. (Canceled) 

30. (Rejected) The apparatus of claim 21, wherein the protection component further 
comprises a filter driver that intercepts and denies requests to access the locally-stored image 
file. 

31. (Rejected) An apparatus for restoring a file system to a partition comprising a 
plurality of allocation units, the apparatus comprising: 

a processor; 

an image locater to find a locally- stored image file located within the partition to which 
the file system is to be restored, the locally-stored image file comprising a directory map and file 
data for a plurality of files; 

a media formatter to initialize at least a subset of the allocation units of the partition not 
occupied by the locally-stored image file including one or more allocation units used for a 
directory area of the partition; 
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a data extractor to extract the file data from the locally-stored image file into the 
initialized allocation units without disturbing the locally-stored image file; 

a directory area builder to build a new directory area for the partition using the directory 
map; and 

a protection component programmed to protect the locally- stored image file from 
accidental user deletion or modification subsequent to creation of the locally- stored image file by 
initiating a process at system startup that opens the locally-stored image file to block subsequent 
processes from accessing the locally-stored image file. 

32. (Rejected) The apparatus of claim 3 1 , wherein the directory map associates names for 
the plurality of files with corresponding portions of the file data, and wherein the directory area 
builder is configured to generate a new directory area for the partition that associates the file 
names with the extracted file data. 

33. (Rejected) The apparatus of claim 31, wherein the directory area builder is configured 
to add an indication of the locally-stored image file to the new directory area. 

34. (Rejected) The apparatus of claim 31, wherein the data extractor is configured to 
decompress at least a subset of the file data. 
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35. (Rejected) The apparatus of claim 31, wherein the directory map indicates at least one 
attribute for a file, wherein the directory area builder is configured to set the at least one attribute 
of the file in the directory area, and wherein the at least one attribute comprises at least one of an 
ownership attribute, an access control attribute, a timestamp attribute, an archival attribute, an 
indexing attribute, an encryption attribute, and a compression attribute. 

36. (Rejected) The apparatus of claim 31, wherein the image locater is configured to 
search for an allocation unit containing a unique beginning-of-image marker for the locally- 
stored image file. 

37. (Rejected) The apparatus of claim 31, wherein the image locater is configured to read 
from a predetermined area of the partition a location of at least a first allocation unit of the 
locally- stored image file. 

38. (Rejected) The apparatus of claim 31, further comprising an image defragmenter to 
defragment the locally-stored image file within the partition before the data extractor extracts the 
file data. 

39. (Canceled) 

40. (Rejected) The apparatus of claim 31, wherein the protection component further 
comprises a filter driver that intercepts and denies requests to access the locally-stored image 
file. 
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41. (Rejected) A method for localized backup and restoration of a file system in a 
partition comprising a plurality of allocation units, the method comprising: 

creating a locally- stored image file by copying each allocation unit occupied by a 
plurality of files of the file system to the locally- stored image file, wherein the locally- stored 
image file is located within the same partition as the file system being backed up; 

adding a directory map to the locally-stored image file that associates copied allocation 
units in the locally- stored image file with names of corresponding files from the file system; 

locating the locally-stored image file within the partition; 

initializing at least a subset of the allocation units of the partition not occupied by the 
locally- stored image file including one or more allocation units used for a directory area of the 
partition; 

extracting file data from the locally- stored image file into the initialized allocation units 
without disturbing the locally-stored image file; 

creating a new directory area for the partition using the directory map; and 
subsequent to creating the locally-stored image file, protecting the locally- stored image 
file from accidental user deletion or modification by initiating a process at system startup that 
opens the locally-stored image file to block subsequent processes from accessing the locally- 
stored image file. 

42. (Rejected) A computer-readable storage medium comprising program code for 
backing up a file system in a partition comprising a plurality of allocation units, the computer- 
readable storage medium comprising: 
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program code for creating a locally-stored image file by copying each allocation unit 
occupied by a plurality of files of the file system to a locally-stored image file, wherein the 
locally- stored image file is located within the same partition as the file system being backed up; 

program code for adding a directory map to the locally- stored image file that associates 
copied allocation units in the locally- stored image file with names of corresponding files from 
the file system; and 

program code for protecting the locally-stored image file from accidental user deletion or 
modification subsequent to creation of the locally-stored image file by initiating a process at 
system startup that opens the locally- stored image file to block subsequent processes from 
accessing the locally- stored image file. 

43. (Rejected) A computer-readable storage medium comprising program code for 
restoring a file system to a partition comprising a plurality of allocation units, the computer- 
readable storage medium comprising: 

program code to access a locally- stored image file located within the partition to which 
the file system is to be restored, the locally-stored image file comprising a directory map and file 
data for a plurality of files; 

program code to initialize at least a subset of the allocation units of the partition not occupied by 
the locally- stored image file including one or more allocation units used for a directory area of 
the partition; 

program code to extract the file data from the locally-stored image file into the initialized 
allocation units without disturbing the locally-stored image file; 

program code to create a new directory area for the partition using the directory map; and 
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program code to protect the locally-stored image file from accidental user deletion or 
modification subsequent to creation of the locally- stored image file by initiating a process at 
system startup that opens the locally- stored image file to block subsequent processes from 
accessing the locally- stored image file. 
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IX. EVIDENCE APPENDIX 

No evidence pursuant to 37 C.F.R. §§ 1.130, 1.131, or 1.132 or entered by the Examiner 
is being submitted. 
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X. RELATED PROCEEDINGS APPENDIX 

As detailed above, a notice of Appeal and a request for Pre-Appeal Conference were 
previously filed in this case on 12 March 2008. The Notice of Panel Decision from Pre-Appeal 
Brief review was mailed on 24 April 2008, a copy of which is included in this Appendix. The 
Panel reopened prosecution. 

Appellant is not aware of any other appeals, interferences, or judicial proceedings that 
will directly affect, be directly affected by, or have a bearing on the Board's decision in this 
appeal. 
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Notice of Panel Decision from Pre-Appeal Brief Review 

iiiiin 

This is in response to the Pre-Appeal Brief Request for Review filed March 12. 2008 . 

1 . □ Improper Request - The Request is improper and a conference will not be held for the following 
reason(s): 

□ The Notice of Appeal has not been filed concurrent with the Pre-Appeal Brief Request. 

□ The request does not include reasons why a review is appropriate. 

□ A proposed amendment is included with the Pre-Appeal Brief request. 

□ Other: 

The time period for filing a response continues to run from the receipt date of the Notice of Appeal or from 
the mail date of the last Office communication, if no Notice of Appeal has been received. 

2. □ Proceed to Board of Patent Appeals and Interferences - A Pre-Appeal Brief conference has been 
held. The application remains under appeal because there is at least one actual issue for appeal. Applicant 
is required to submit an appeal brief in accordance with 37 CFR 41 .37. The time period for filing an appeal 
brief will be reset to be one month from mailing this decision, or the balance of the two-month time period 
running from the receipt of the notice of appeal, whichever is greater. Further, the time period for filing of the 
appeal brief is extendible under 37 CFR 1 .136 based upon the mail date of this decision or the receipt date 
of the notice of appeal, as applicable. 

□ The panel has determined the status of the claim(s) is as follows: 

Claim(s) allowed: . 

Claim(s) objected to: . 

Claim(s) rejected: . 

Claim(s) withdrawn from consideration: . 



3. □ Allowable application - A conference has been held. The rejection is withdrawn and a Notice of 
Allowance will be mailed. Prosecution on the merits remains closed. No further action is required by 
applicant at this time. 

4. El Reopen Prosecution - A conference has been held. The rejection is withdraw^ 
action will be mailed. No further action is required by applicant at this time. 
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